home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1995 October
/
EnigmA AMIGA RUN 01 (1995)(G.R. Edizioni)(IT)[!][issue 1995-10][Aminet 7].iso
/
Aminet
/
comm
/
fido
/
SHELTER275.lha
/
DOCS
/
xpremsi.doc
< prev
Wrap
Text File
|
1994-09-19
|
14KB
|
375 lines
A Library for EMSI handshake for WPL Mailers by Gordon Normand
XPRemsi.library is an XPR v3 library for Shelter Mailers that talks
directly to wpl.library. It does not work with any other XPR host. It is
not a direct replacement for the restricted distribution wplemsi.library,
but can be used in those environments with some wpl code modification.
The library simply sends and receives EMSI packets and calculates CRCs.
All values to be sent must be set by the host mailer. Any action to be
taken based upon received values is up to the host mailer.
Much of this documentation is based upon public messages from Robert
Williamson, the author of the Shelter Mailers, in the FIDONET echos NET_DEV
and WELMAT and in the INTERNET WPL mailing lists. Much information was
also gleaned from the Porticus Mailer WPL code. This powerful EMSI
implementation is the most extensive available on the Amiga.
References:
WPL.Language, wpl application developers language reference,
WPL.Programmer, wpl developers interface reference,
by Russell McOrmond
FSC-0056.001, The EMSI/IEMSI Protocol Definitions
by Joaquim H. Homrighausen
EMSI-II, EMSI/IEMSI Protocol Clarifications and Enhancements
by Robert Williamson
Calling:
Inbound Calls:
XprSetup xpremsi.library ""
XprReceive ""
XprClose
set RC $(EMSI)
Outbound Calls:
XprSetup xpremsi.library ""
XprSend ""
XprClose
set RC $(EMSI)
$(EMSI) is TRUE if handshake was OK, else FALSE.
The following variables should be set before calling the xpr.
${WPLNAME}
An environmental variable which contains a string with the name
and version of the host mailer.
$(baud)
The current link rate (modem<->modem, automatically set).
$(remote.password)
The password for the remote site as defined in site cache or
nodelist.
$(host.akas)
A list of addresses in EMSI format:
zone:net/node[.point][@domain]
The first AKA is considered to be the PRIMARY address, and
should be one's address in the domain of the site we are calling.
$(host.phone)
full phone number as in nodelist
$(host.baud)
max bps as in nodelist
$(host.flags)
nodelist flags as in nodelist
$(host.sysop)
sysop names as in nodelist
$(host.city)
location as in nodelist
$(host.sitename)
system name as in nodelist
$(host.serial)
name and version info set by host application
$(host.freq)
If false, the NRQ flag will be sent for INBOUND calls.
$(host.link)
$(host.compat)
see below
Additional EMSI fields can be added, if the following convention is
followed:
Set host.flags "$(host.flags)]}{TRX#}{[$(RESULT2)]}{[UTC]}{[${TZ}"
As can be seen, the additional fields are tacked on to the host.flags
variable. The library adds the data field's [,],{ and } to the variables
contents. The first pair of "]}" terminate the emsi IDENT structure, the
final pair is added by the library itself.
If the handshake was successful, the following variables will be set.
host.compat
set to selected protocol (see below)
remote.akas
a list AKAS in EMSI format (zone:net/node[.point][@domain])
the first AKA is considered to be the PRIMARY address.
remote.address
set to primary address in EMSI format
remote.freq
this variable is set FALSE if remote site presents HRQ
remote.password
the password the remote site presented
remote.link
remote.compat
see below
remote.product
FTSC product code
remote.mailer
Mailer name
remote.version
Mailer version
remote.serial
serial number or other product specific identification
remote.extra
remote.sitename
remote.city
remote.sysop
remote.phone
remote.baud
remote.flags
All the above are the remote sites system information. This
may or may not be the same as what apprears in the Nodelist entry
for that site.
remote.time
transaction timestamp
The remainder is extracted from Robert Williamson's EMSI-II
specification and is used by permission. The extract describes the EMSI
Link and Compatibity flags which are direcetly related to the host. and
remote. link and compat variables.
Link and Compatibility Flag Processing:
Link Flags:
Link flags consist of a string of codes that specify DESIRED CONNECT
CONDITIONS. They apply to the CURRENT SESSION ONLY. There are three TYPES
of link flags: communications parameters, pickup options and hold options.
Link Communications Parameters:
Presented by both the calling system and answering system, this flag
defines the communications link data bits, stop bits and parity parameters.
The purpose of this flag is unclear however, my assumption is that it is
expected that one end or the other change his communications parameters to
match. The specification does not say which end must compromise, nor what
to do if a) no compromise is possible, b) software does not support
changing these parameters while connected. Obviously, if only one end
changes link parameters, the session will fail.
Pickup and Hold Flags:
Under a strict interpretation of the EMSI specification, Link Pickup
flags are only presented when calling (an Outbound Session) and are
examined and processed only when answering (an Inbound Session) and Link
Hold flags are only presented when answering (an Inbound Session) and are
examined and processed only when calling (an Outbound Session).
Some mailers optionally present BOTH Pickup and Hold flags during
EITHER type of session. However, there is no requirement that the system
received such a presentation take an action on flags not specified for the
type of session. There are also no guidelines how to handle conflicts that
may arise in iterpretation.
Link Pickup options:
The calling system can present one of three Link Pickup options
related to pickup of mail. These are presented during OUTGOING calls and
examined during INCOMING calls.
/ PUA Pickup mail for all presented addresses.
one of | PUP Pickup mail for primary address only.
\ NPU No mail pickup desired.
If none of these flags are presented, PUA is to be assumed.
If only one address is presented, neither PUP nor PUA should be
presented, as this would be redundant. NPU is valid however.
PUA:
This flag is presented if our tosser is zone and/or domain aware.
This flag is not examined, since sending all mail for all KNOWN
akas is the default action under EMSI. The action to take if NO Pickup
flag is presented is undefined in the EMSI spec. We assume PUA.
Note: KNOWN akas are those addresses of a site for which one packs
mail. Since no traffic exists for a sites other unKNOWN AKAS, they are of
no interest and are ignored.
PUP:
This flag is presented if our tosser is not zone and/or domain
aware. On outgoing calls the Primary address is always that address in the
domain of the site we are calling. We will still present PUP, but this is
redundant.
When examined, mail is sent for Primary (first) address presented.
NPU:
This flag is presented when using the NOPICKUP session option. The
presentation of NPU is a courtesy measure ONLY, since we hangup after
sending our mail.
When examined, NO files are sent, mail or OTHERWISE, UNLESS the
remote also presented PUP. This would be an error on his part, but we
ignore that fact :) and just give him what he wanted.
Link Hold options:
When answering, the site can present Link Hold flags which are
requests to the calling site to not send certain types of files. These
flags should be presented only on incoming calls and examined only on
outgoing calls.
HRQ Hold file requests (not processed at this time).
and/or
/ HAT Hold ALL traffic.
one of |
\ HXT Hold compressed mail traffic.
HRQ:
This flag is presented during UMH if STRICTZMH is TRUE.
This flag is also presented if file request processing is disabled
TEMPORARILY for any reason.
When examined, file requests are not sent to remote site.
HAT:
Presented if inbound free space has fallen below a preset limit.
When examined, no files are sent, but files can be received.
HXT:
This flag is presented during UMH if STRICTZMH is TRUE.
When examined, system specific processing determines what files are
sent.
Note: STRICTZMH would mean that only netmail packets may be sent or
received. There should be no file request accepted or processed, no
arcmail accepted or sent and no fileechos (TIC's) accepted or sent.
Compatibility Flags:
Compatibility flags consist of a string of codes that specify the
CAPABILITIES (protocols and archivers) and ENABLED FEATURES (file request
handler, filename conversion) of the mailer.
Standard Protocol Flags:
NCP No common protocol ( a failure )
DZA DirectZAP (Zmodem variant).
ZAP ZedZap (Zmodem variant).
ZMO Zmodem w/1,024 byte data packets (Wazoo ZedZip).
JAN Janus
KER Kermit
SLK SeaLink
Extended Protocol Flags:
TEL Telink (FTS1)
XMO Xmodem (DietIFNA)
YMO Ymodem
UUG uucp-g
HYD Hydra
NCP:
This is presented if no compatible protocols (failure). It logged
if the remote presents it. Since in most networks, a common protocol DOES
exist, we fall back to that protocol, DietIFNA.
Note: Versions of Binkley, Porticus, Gazebo, Umbrella and JamMail
feature DietIFNA fallback.
Other Compatibility flags:
NRQ No file requests accepted by this system.
NRQ:
This flag should be presented if there is NO FILE REQUEST HANDLER.
ie the system NEVER accepts file requests.
When examined, No requests will be sent.
**NOTE:
It seems some mailers present NRQ as the caller's version of HRQ.
I consider this action to be incorrect since:
- Well written mailers NEVER process requests received during outbound
sessions
- NRQ flag indicates NO REQUEST SERVER AVAILABLE
- HRQ flag indicates NO REQUESTS AT THIS TIME.
- Under WAZOO, the lack of a NODELIST X? flag can be seen as
the equivalent to EMSI presentation of NRQ
NRQ should be presented ONLY IF the mailer does not have a file
request server. It should NOT be used to indicate that the function is
temporarly disabled.
If the author of the EMSI specification had intended that NRQ be
the caller's version of HRQ, why then are there separate LINK and
COMPATIBILTY flags, if they are not consistanty applied? Why was there any
distinction made between calling and answering system LINK flags? It would
be more consistant if ALL LINK flags be presentable by either system.
In fact, for consistancy, the chosen protocol should also be
presented as a LINK flag.
ARC ARCmail 0.60-capable, as defined by the FTSC.
NO ACTION required, information is of little value.
XMA Site supports other forms of compressed mail.
NO ACTION required, information is of little value.
FNC Filename conversion. This indicates that any transmitted
filename must follow the CP/M & MS-DOS 8.3 restriction.
An eight character file name followed by a three character
extension; eg. FILENAME.EXT
**NOTE:
Since FNC is a COMPATIBILITY flag, it SHOULD be interpreted to mean
that the system presenting FNC is advertising the CAPABILITY to send 8.3
file names. If the intention of the author of the EMSI spec was that this
was a request for the other end to modify filenames, this should have be
stated. The word 'received' should have been used instead of 'transmitted'
and the FNC flag should have been defined as a LINK flag for consistancy in
the specification.
Accepting the fact the some systems actually intend the flag to be a
request for the remote to convert filenames before sending, I have added
this capability to RFH, my file request handler. FNC conversion is not
required for mail or packets since the transmitted filenames always conform
to the FTS-LIST specifications.
While doing this, it occured to me that the above spec is somewhat
unclear. Specifically, it does not mention what characters may be illegal
in cp/m and msdos filenames. In fact, since this flag may be used by
mailers on other platforms, simply stripping such characters is
insufficent. Other platforms use characters in filenames that are illegal
under msdos and msdos uses characters that are illegal on other platforms.
Therefore, it would seem advisable that any FNC function should:
- Strip ALL punctuation including embedded periods,
except for the last period (.) which now separts the name and
extension fields.
I strip: '20'x-'2f'x, '3a'x-'40'x, '5b'x-'60'x, '7b'x-'7f'x
- Convert to UPPERCASE
- pad each field with trailing '0's to insure they are at least 8
and 3 in length
- re-build the filename from the FIRST and LAST 4 characters of the
name field and the FIRST three characters of the extension field.